@jnahmias
Thank you!

The test file name is gh9498_1.phpt. Are you planning on adding multiple tests? If there is only one, it may be better to remove the _1.

The other changes look good to me, but I'll wait for other people's opinions.

edit:
We need to be able to skip tests somehow. I can't think of a way to do that right now...

FWIW this is kinda similar to what ibm_db2 and friends do with their i5_dbcs_alloc option, except it also does it for non-wchar columns because of the treachery of EBCDIC to UTF-8 conversions (and has to assume all astral plane on the UTF-8 side, so 6 bytes per character). It's a bit of a hack, but doing things "right" would be more complicated last time I looked into it.

https://github.com/php/pecl-database-ibm_db2/blob/master/ibm_db2.c#L1991-L2005

The test file name is gh9498_1.phpt. Are you planning on adding multiple tests? If there is only one, it may be better to remove the _1.

@SakiTakamachi: Yes, I have another test planned for the INSERT path; see phpGH-9498 for details; However, from my review it seems to be a deeper issue that is only somewhat related (and probably should be a separate issue) so I have not made it part of this PR. Happy to rename it without the suffix if that's desired.

Hmm, I'm really unsure how to solve this issue, but I think regardless of the exact solution, we should add more common routines for ext/odbc and ext/pdo_odbc to main/php_odbc_utils. Otherwise we likely end up solving similar issues twice.

Comming back to the issue at hand: how does ext/odbc behave in this regard?

Comming back to the issue at hand: how does ext/odbc behave in this regard?

Yeah, somewhat similar but rather different (see odbc_bindcols()).

Also somewhat related to PR #10809.

Yeah, that old PR did solve some problems I had that were similar, although I was still unsure if it was the right solution, especially as it might have had some performance impact.